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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.l], and has been converted to a TS because the 
language used in the document is akin to that of a TS. 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 3, sub-part 1 of a multi-part deliverable full details of the entire series can be found in 
partl.TS 102 542-1 [i.2]. 



ETSI 



ETSI TS 102 542-3-1 V1.3.1 (2010-01) 



Scope 



The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 version 4: 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the Handbook. 

Part 3 of this multi-part deliverable deals with Error recovery technologies. The present document provides a 
presentation of error recovery technologies within DVB-IPTV, and some elements of comparison between them. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 542: "Digital Video Broadcasting (DVB); Guidelines for DVB IP Phase 1 

Handbook" . 

[i.2] ETSI TS 102 542-1: "Digital Video Broadcasting (DVB); Guidelines for the implementation of 

DVB-IPTV Phase 1 specifications; Part 1: Core IPTV Functions". 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AL-FEC Application Layer - Forward Error Correction 

CoD Content on Demand 

DVB Digital Video Broadcasting 

HNED Home Network End Device 

IP Internet Protocol 

IPTV IP Television 

LMB Live Media Broadcast 

RET RETransmission 



Packet loss recovery in DVB-IPTV 



The DVB-IPTV Handbook [1] defines two solutions for real-time services (LMB and CoD) error recovery. Here is a 
very brief presentation: 

• Annex E specifies the Application Layer Forward Error Correction (AL-FEC) technology. 

The AL-FEC is based on parity packets sent along with the content packets. Those parity packets allow the 
receiver to rebuild missing packets from the content flow. 

• Annex F specifies the Retransmission (RET) technology. 

The RET is based on the interaction between the receiver and a server. When detecting a missing packet, the 
receiver request the server to send again that packet. 



5 Discussion on pros/cons of AL-FEC and RET 

DVB-IPTV has defined those two solutions for error recovery: AL-FEC and RET. The two solutions are significantly 
different in many aspects and it is not possible to say that one solution is better than the other. Furthermore, the two 
solutions can also be combined, but again it is not possible to say that this results in a better solution compared to any 
single solution standalone, as there are many factors at stake. 

In this clause the two solutions are compared on a few aspects, without leading to an overall conclusion, except for the 
fact that for each particular scenario, the IPTV service provider shall carefully assess his needs and evaluate these 
against the trade-offs that are provided by either AL-FEC or RET or a combination of both. 



5.1 Network Aspect 



A key characteristics of the DVB RET service is that a DVB RET server functionality is required in the network. For 
CoD service, this RET server function may be integrated with the CoD streaming server function. For the LMB service, 
a single element (the head-end) streams content over a multicast distribution to many HNEDs (possibly hundreds of 
thousands) and there may be multiple DVB LMB RET servers provisioned in the network. A DVB LMB RET server 
will basically cache for a limited time frame LMB service IP packets making them available for retransmission when 
HNEDs detect and report packet loss. The amount of LMB RET servers required in the network for packet loss 
recovery of LMB services, will be dependent on the number of HNEDs provisioned with a RET client, network 
topology considerations and network packet loss characteristics. The DVB LMB RET server basically interacts in 
unicast mode with DVB RET clients, but the RET server may also interact in multicast mode with RET clients. 

With AL-FEC packet loss protection, the streaming source transmits parity packets along the CoD/LMB service stream 
packets by, anticipating possible packet loss. When there is packet loss, the extra parity packets allow an HNED to 
restore the original stream. This solution stems from the broadcast world and there is no two-way interaction between 
the HNEDs and the Streaming Source (Head-End or CoD streamer), nor the need for additional servers in the network. 
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5.2 Bandwidth Aspect 



With RET the average bandwidth overhead required on the access link (between the home network or HNED and the 
access node) represents approximately the observed packet loss ratio. The possible peak RET bandwidth overhead 
(e.g. when several consecutive packets are lost) will be similar as the fixed overhead required by AL-FEC when the two 
solutions have the same packet loss protection capability (amount of packet losses that can be recovered in a specific 
time frame). However, services that are treated/offered with lower priority/QoS compared to the priority/QoS of an 
CoD/LMB service that is enabled with RET packet loss protection, can make use of this peak RET bandwidth budget 
that is in most cases not consumed by RET. This is in contrast to AL-FEC, where the AL-FEC bandwidth overhead is 
fixed and constant. 

The AL-FEC bandwidth overhead budget in the aggregation and core network segment for LMB services only needs to 
scale with the number of LMB services, whereas for RET, the bandwidth budget that must be provisioned must take 
into account the amount of HNEDs serviced with RET. A particular challenge for LMB RET service is also to be able 
to withstand or avoid retransmission request storms when there is LMB service packet loss on a shared network link 
(e.g. in the core network) impacting many HNEDs simultaneously. The DVB RET protocol for LMB services has 
several built-in features that allow to handle this kind of events, e.g. by means of multicast retransmission and/or 
pro-active multicast signalling of packet loss (optionally) combined with having the RET client respecting a 
retransmission request waiting time upon packet loss detection. 

5.3 Combination of AL-FEC and RET 

AL-FEC may be combined with RET in such a way that video streams may have default AL-FEC protection, but 
additionally there is also the possibility to make use of a RET service. This solution is referred to as hybrid 
AL-FEC/RET. With the hybrid AL-FEC/RET solution the operator chooses to use a "light version" AL-FEC protection, 
which may not be able to correct all packet losses. Those packet losses that are not correctable by the AL-FEC result in 
RET requests and retransmissions. 

The advantage compared to a AL-FEC only system, is the lower fixed bandwidth overhead on the access links, but there 
is the need to still provision RET server functionality in the network or at the CoD streamer. Furthermore there is 
possibly a higher end-to-end delay. 

The advantage compared to a RET only system is that fewer RET server function instantiations are needed (LMB 
services) and/or the RET server instantiation can be dimensioned smaller. This is though at the cost of higher average 
bandwidth overhead on the individual links, the need for an AL-FEC decoder in the STB, and a possible higher 
end-to-end delay because of the fact that the protection periods for RET and AL-FEC are cumulative. 

NOTE: The end-to-end delay defined here is the time elapsed between the moment when the video services 
content is streamed into the network and the moment this content is displayed by the HNED. The 
capturing and encoding time is not taken into account since it is not relevant in this context. 
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